Memory devices find ubiquitous use in electronic devices, such as in consumer electronics. Memory devices are typically used to store executable code and data for the runtime operation of the electronic device. Many electronic devices stay operating almost continuously for long periods of time, potentially transferring large amounts of data in and out of the memory devices. Thus, it is important that the memory devices perform according to design expectations. However, memory devices are subject to failure from design issues or manufacturing inconsistencies. The failures can show up right after manufacturing as well as in operation of the devices.
Memory testing is used to detect abnormalities or other unexpected behavior in the memory devices. Some memory tests are subtle I/O (input/output) failures or failures with memory array cells. Some I/O failures usually require a specific combination of power supply noise, crosstalk, and ISI (inter-symbol interference). The ISI could come from either interference due to previous unit intervals (UIs) of a current burst, or from prior bursts (for example, due to turnaround time on the bus). As a result, fully testing the I/O can be very difficult due to the specific sequences required to reliably create the necessary conditions for failure.
Similarly, failure in the memory device arrays can be very difficult to reliably create. Many cell failures only occur under the condition of very specific access patterns. Failures in the memory array often require triggering a specific corner case that affects marginal conditions of a memory device circuit.
Traditional testing solutions used testing mechanisms that were either fixed function hardware finite state machines (FSMs) or to execute a test in software. Software solutions suffer at least the problem of the software needing to go through multiple levels of processing and scheduling, which can result in out-of-order execution of the software test operations. For example, the software instructions can be processed and scheduled through the core (e.g., the processor(s)), the uncore (e.g., system architecture elements that connect the processor cores), and memory controller. The software instructions are also subject to filtering in the various cache levels of the processor(s). Thus, the instructions go through too many levels of processing to guarantee the operation of the test, and cannot precisely target what areas of the memory device are affected when desired.
Hardware FSMs can operate much closer to the memory controller and avoid many of the issues associated with many levels of processing. However, traditional hardware FSMs are very fixed function machines that execute a single test type. Additionally, traditional hardware FSMs operate at the memory device command level, injecting the specific commands they want the memory devices to execute.
Furthermore, whether with software testing mechanisms or hardware FSMs, traditional tests have ignored the impact of power down modes, refresh operations, ZQ (termination resistor) configuration, and the use of maintenance commands. Thus, traditional testing mechanisms have not done anything to synchronize their operation with the runtime operation of the system and its interaction with the memory device and the memory controller.
Descriptions of certain details and implementations follow, including a description of the figures, which may depict some or all of the embodiments described below, as well as discussing other potential embodiments or implementations of the inventive concepts presented herein.